-
Notifications
You must be signed in to change notification settings - Fork 145
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
installed headers don't compile #4798
base: master
Are you sure you want to change the base?
installed headers don't compile #4798
Conversation
8eea16c
to
77bf820
Compare
I thought your plan is to prefix in all |
That was my plan (#3044), but until now I hadn't properly considered if or how these headers work when they're installed for use by third-party software that wants to link against libcyrus, and it turns out that's been broken by some of my changes in this direction. Hopefully, cleaning it up enough for the abi-compatibility-checker to work will shake out the issues, and reveal a clear path forward. |
417c56a
to
7150603
Compare
I do not understand how installing or not a header somewhere under |
It's not, really. The Debian people needed to know whether the ABI would be compatible when they change some of their 32 bit platforms to use 64-bit time_t. They have a tool to check for this automatically, but it wants to compile the installed header files, which fails because some of them rely on stuff like config.h which isn't installed. We've since established that the packages won't be ABI compatible, and so the Debian people will set their packages up to accommodate that. The tool no longer matters particularly... but the installed headers are still broken. So it's not that the headers are a problem for ABI compatibility; they're a problem because they don't compile. It just so happens that it was the ABI compatibility checker that made us notice they don't compile. |
9a3d4d2
to
0efb0e8
Compare
My understanding now is, that cyrus-imap installs header files, which in some way depend on |
0efb0e8
to
07a3120
Compare
When our headers are installed, they're no longer buried under a "lib/" subdirectory, which means installed headers using this spelling can't find their dependencies, and that means third party code that wants to link against libcyrus et al cannot be compiled. Installed headers must spell it `#include "foo.h"`, not `#include "lib/foo.h"` md5.h is not installed, so the spelling it uses should not make a difference. xsha1.h is not installed, but ought to be. I've fixed the spelling in both of these for consistency
Needed by charset.h, which is installed. Based on cyrusimap#4623, originally by @dilyanpalauzov
That is: we can't install headers that depend on headers that aren't installed
…cess env don't ever assume the Cyrus install path is in the user's ld.so.conf
(and fix the name conflicts to make this possible)
this should probably be in Libs.private, but example_libcyrus.c needs libcyrus_min because it calls config_read, and i'm pretty sure it has to call config_read, and so it should really link against libcyrus_min itself rather than relying on libcyrus to bring it in, but that complicates the LibCyrus.pm setup, which would need to know about the multiple dependencies... ---- actually, i think the above comment is bogus, and this commit is correct. pc(5) says Libs.private is for static linking, not for differentiating a library's own dependencies from those a caller needs need to check the other libfoo.pc.in files and make them all coherent...
... rather than from file name, so that examples can easily express multiple dependencies
07a3120
to
0afca14
Compare
The Debian package maintainer privately reported a problem from the abi-compatibility-checker not being able to run due to the installed headers not compiling. This is part of Debian's work to switch to 64-bit time_t on some 32-bit platforms. Further details in https://cyrus.topicbox.com/groups/devel/T7b15dfc105949d4e-Meae606200efd965cc932318f
I'm using this PR to accumulate the fixes that we need to get the abi-compatibility-checker to actually run.